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TITLE OF INVENTION 

EVENT ROUTER AND METHOD FOR HANDLING EVENTS 
IN DISTRIBUTING COMPUTING APPLICATIONS 

CROSS REFERENCE TO RELATED APPLICATION 
The present application claims the benefit of U.S. Provisional Application 60/380,381 
filed on May 13, 2003, the entire disclosure of which is incorporated herein. 

BACKGROUND OF INVENTION 
A distributed system is a collection of autonomous computing entities, hardware or 

software, connected by some communication medium. While often the computing entities axe 
geographically dispersed, in some instances they might be separate processors in a multi- 
processor computer or even separate software routines executing in logically isolated memory 
space on the same computer. A computing entity need not be a traditional computer, but more 
generally can be any computing device, ranging &om a large mainfirame to a refrigerator or a cell 
phone. A distributed application is an application that executes on a distributed system and one 
in which parts of the application execute on distinct autonomous computing entities. 

Whenever a distinct component of a distributed apphcation requests somethmg (e.g., a 
data value, a computation) of another component, the former is called a client and the latter is 
called a service. It is worth noting that the terms service and client are not exclusionary in that 
an item can be both a client and a service. For example, a routine that calculates the time 
between two events may be a client of a clock service; if the clock service then calls a routine 
that converts to Daylight Savings Time, the clock becomes a client and the Daylight Savings 
Time converter is its service. 
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Figure 1 shows a typical distributed application of the existing art. There are two clients 
2, 4 and four services 10, 12, 14, 16 that the clients 2, 4 might need. Each service has a service 
proxy 10a, 12a, 14a, 16a which is a module of mobile code that can be used by clients to invoke 
that service. A service proxy 10a, 12a, 14a, 16a contains the code needed by a client 2,4 to 
5 interact with a service. For instance if a service is a digital camera on a robotic ann, tlie 

interfaces might include initializeQ, zoomQ, rotateQ and get^PictureQ. The service proxy 10a, 
12a, 14a, 16a may also provide the expected return values for the service, which might include 
error codes as well. 

Mobile code generally refers to a computer program that can be written on one platform 
1 0 and executed on numerous others, irrespective of differences in hardware, operating system, file 
system, and many other details of the execution environment. In addition to independence from 
the physical characteristics of the execution environment, a mobile program may move from one 
computer to another in the middle of its execution. 

Mobile code may be pre-compiled, or compiled when it arrives at the execution platform. 

15 In the first case, numerous versions of the program must be written and compiled, then matched 
across run-time enviroimaents; this is mobile code in the letter, but not the spirit, of the 
definition. In addition, the same pre-compiled program cannot move from one platform to a 
different one during its execution. In the second, the program text may be distributed along with 
configuration scripts describing what to do in each execution envirorunent. This distributes and 

20 delays the specificity of the pre-compiled option. The more interesting, and far more common 
approach exploits a standard virtual machine, which finesses all the issues of platform 
heterogeneity. The virtual machine is a program that itself mitigates the machine dependencies 
and idiosyncrasies, taking the raw program text and compiling it to a binaiy executable. 
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In addition to clients 2, 4 and general services 10, 12, 14, 16, all distributed applications 
need some mechanism for clients 2, 4 to find services. Often such knowledge is assumed a 
priori, but many distributed applications use a look-up service 20. The look-up service 20 is a 
service with which the other services are registered or advertised to be available for use by 
5 clients. In a simple system, where there is no attempt to coordinate replicas of services, each 
new service registers with the look-up service 20 (in the case of replicas, tlie onus falls on the 
client to resolve conflicts and ambiguity). When a service 10, 12, 14, 16 registers, it provides 
information telling clients 2, 4 how to find it Commonly, this is a physical location such as an 
IP address and port nximber, but in the most modem systems this can be as powerfiil as giving 

.0 the look-up service 20 a service proxy 10a, 12a, 14a, 16a, which is actual mobile code that 
clients 2, 4 can execute and use to invoke that service 10, 12, 14, 16. In this way, the service 
proxy 10a, 12a, 14a, 16a contains not just location information but information for how to use 
the service 10, 12, 14, 16. While just as necessary for the client 2, 4 as location information, this 
has previously been assumed as a priori knowledge. When a client 2, 4 wishes to work with a 

15 service 10, 12, 14, 16 it finds it through the look-up service 20, downloads the service proxy 10a, 
12a, 14a, 16a for that service 10, 12, 14, 16 firom the look-up service 20, then uses the service 
proxy 10a, 12a, 14a, 16a to invoke the service 10, 12, 14, 16. The look-up service 20 may also 
have attributes of the services 10, 12, 14, 16, such as whether it is a grouped service, what type 
of group it is, what its cost to use is, how accurate it is, how rehable it is, or how long it takes to 

20 execute. In such cases the clients 2, 4 can use the attributes to decide which of a number of 
services 10, 12, 14, 16 it wishes to xxse. 

Each of the foregoing has access to a communication network 22 so that it is capable of 
communicating with at least some of the other members in the distributed computing application. 
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The communication network 22 may be wireless, a local area network, an internal computer bus, 
a wide area network such as the Internet, a corporate intranet or extranet, a virtual private 
network, any other communication medium or any combination of the foregoing. 

In the prior art example shown in Figure 1, one client 2 is a traffic monitoring program 
5 that notifies a user when and where traffic has occurred and the other client 4 is an automated toll 
collection program. The services are a clock 10, a road sensor 12 that monitors traffic flow on a 
highway, a toll booth sensor 14 that detects an ID device in each car that passes through the toll, 
and a credit card charge program 16. When each service 10, 12, 14, 16 becomes available to the 
application it registers with the look-up service 20 and provides the look-up service with its 
10 service proxy 10a, 12a, 14a, 16a. 

When the traffic monitoring client 2 begins, it queries the look-up service to see if a clock 
is available and what sensors are available. The look-up service 20 responds by providing the 
client 2 with the clock proxy 10a, the road sensor proxy 12a and the toll booth sensor proxy 14a. 
The traffic monitoring client 2 uses the service proxies 10a, 12a, 14a to invoke the clock 10 and 
1 5 the sensors 12, 14, and then to monitor traffic at various times of the day. 

Similarly when the toll collector client 4 begins, it queries the look-up service 20 to see if 
a toll booth sensor 14 and a credit card charge service 16 are available. The look-up service 20 
responds by providing the client 4 with the toll booth sensor proxy 1 4a and the credit card charge 
proxy 16a. The toll collector client 4 uses the service proxies 14a, 16a to invoke the toll booth 
20 sensor 14 and the credit card charge program 16, and then to identify cars that pass through the 
toll booth and charge their credit cards for the toll. 

Another technique known in the existing art is leasing. A lease is an important concept 
throughout distributed computing, generally used between a client and service as a way for the 

-4- 
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service to indicate its availability to the client for a length of time. At the end of the lease, if the 
lease is not renewed, there is no guarantee of availability . In a simple example, a service may 
register with a look-up service and be granted a lease for five minutes. This means that the look- 
up service will make itself available to the service (i.e., list it) for five minutes. If a camera 
5 grants a lease to a client for two minutes, then that client will be able to position, zoom, and take 
pictures for two minutes. There are a wide variety of ways to handle lease negotiation, renewal 
and termination which are well known to those skilled in the art of distributed computing and all 
such methods are meant to be incorporated within the scope of the disclosed invention. A 
detailed explanation of leases can be found in, Jim Waldo, The Jini Specification, 2nd Edition^ 
10 chapter LE (2001), which is incorporated herein by reference. 

Some benefits of distributed computing and mobile code can immediately be seen from 
this example. First, the clients 2, 4 in Figure 1 do not need to know ahead of time which sensors 
12, 14 are available, or even how many. They simply query the look-up service 20, which 
provides this information along with the necessary mobile code 12a, 14a to call the sensors. 

15 Similarly, the clients 2, 4 do not care which clock 10 is available, as long as any clock 10 is 
available. Again, this is because through the use of mobile code, a client 2, 4 is provided with 
the necessary service proxy 10a to invoke and work with the clock 10. Also, the failure or 
unavailability of a single sensor 12, 14 or other service is not likely to cause the entire 
application to stop rumiing. Further, the processing load is distributed among a number of 

20 computing devices. Also, the various computing entities need not use the same operating 
system, so long as they conform to a common interface standard. 

Jini is one example of a commercially available specification for a distributed object 
infrastructure (or middleware) for more easily writing, executing and managing object-oriented 

-5- 
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distributed applications. Jini was developed by Sun Microsystems and is based on the Java 
programming language; consequently, objects in a Jini system are mobile. Jini is described in 
Jim Waldo, The Jini Specification, 2nd Edition (2001). The Common Object Request Broker 
Architecture (CORB A), developed by the Object Management Group, and Distributed 
5 Component Object Module (DCOM), developed Microsoft Corporation, are two other 

commercially available examples that are well known in tiie prior art. Jini, DCOM, CORBA and 
a number of other distributed computing specifications are described by Benchiao Jai et al., 
Effortless Softwai'e Interoperability with Jini Connection Technology, Bell Labs Technical 
Journal, April- June 2000, pp. 88-101, which is hereby incorporated by reference. 

10 Distributed computing systems with groups can also be found in the prior art, particularly 

in the academic literature. For example, 02alp Babaoglu et al., Partitionable Group 
Membership: Specification and Algorithms, University of Bologna, Department of Computer 
Science, Technical Report UBLCS-97-1 describe groups, but assumes the services in the group 
are group-aware. Similarly static group proxies, or software wrappers, for clients have been 

15 described in Alberto Montresor et al Enhancing Jini with Group Communication, University of 
Bologna, Department of Computer Science, Technical Report UBLCS-2000-16, but these group 
proxies cannot be modified during execution of the distributed application to accommodate 
changes in group make-up and structure. 

Another well known concept in the prior art of distributed computing is that of a tuple 
20 space. Within the Java language Tuple spaces are specifically known as JavaSpaces. A Tuple 
space is a hybrid of a database, a file system and a librarian. Tuple spaces are active, in that they 
are not only capable of providing data if it is available, but can notify users when information 
they are looking for has been entered. Tuple spaces are repositories of objects. Applications can 
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put an object into a Tuple space. This makes it available to other members in the distributed 
environment. Applications can query Tuple spaces to see if a particular object or type of object 
is in the space. Applications can subscribe to a Tuple space so that they are notified when an 
object or type of object they have requested is placed in the space. AppUcations can read or take 
5 objects fi-om a Tuple space. The difference between reading and taking is that reading leaves the 
object in the space for other services to read or take, while taking removes the object fi-om the 
tuple space. Typically the objects in Tuple spaces have been data or data files. 

It is known in the prior art for objects to emit events upon the occurrence of certain 
conditions. An event is a message pushed by or firom an object to one or more other objects that 

10 are capable of receiving and interpreting the event. The object sending the event is known as 
the generator, emitter or source. The object receivmg the event is Icnown as the listener. Events 
may be emitted upon the change of any state in an dbject. Examples of events are occurrence of 
an error, the successful completion of all or part of a taslc, a security breach or a periodic notice 
that the emitter is still functioning. 

1 5 In the prior art, listeners have been hard-coded to receive events of importance to tliem; 

this has been achieved by invoking a file transfer protocols (reading a file of events), initiating a 
socket or other communication session with the event source, or subscribing to an event stream. 
In a Jini system, a listener may use the discovery protocol and the look-up service to find 
generators of events of specific types (e.g., all alarm events, or all complete events). The listener 

20 ' then registers with the event generators for some or all events available and the event generator 
notifies the listener upon the occurrence of the stated events. In registering for the event the 



Ustener gives the generator its proxy so that the generator has the appropriate communication 
syntax and protocol to communicate with the listener. The use of the events in distributed 



-7- 



wo 03/096212 PCTAJS03/15028 - 

systems is well known in the prior art and is described in Jim Waldo, The Jini Specification^ 2nd 
Edition, Chapter EV (2001), which is incorporated herein by reference, 

BRIEF DESCRIPTION OF THE INVENTION 
The present invention is a method and system for automatmg the establishment of 
5 generator-listener communication within a distributed environment. A software module known 
as an event router monitors objects present in the distributed environment and registers listeners 
with generators according to a set of rules established within, or accessible to, the event router. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows an example of a distributed computing application of the prior art. 

10 Figure 2 shows a block diagram of a distributed system with a plurality of sources and 

listeners and an event router. 

Figure 3 shows an example of an event router routing events to a JavaSpace. 

. DETAILED DESCRIPTION OF THE INVENTION 
1 5 The present intervention is a software module termed an event router. The event router is 

used to establish connections between event generators and event listeners without affecting 
listeners; the rules determining which generators and listeners are connected are dynamically 
modifiable and may be accessed by the event router fi-om other modules, thus enabling modules 
with specific environmental analytics to influence the routing of events. The event router may 
20 also provide wrappers for listeners' proxies that can enhance the generator-listener connection. 
For example, the wrapper may perform all tasks associated with maintaining the generator- 
listener connection (e.g., in a Jini system, the Ustener is given a lease which must be renewed if 
the connections with the generator is to be maintained). In general, the event generator removes 
the burden fi-om listeners of explicitly having to register with event generators, making the 



-8- 



wo 03/096212 PCTAJS03/15028 

V 

connection to generators dynamic and controllable according to ambient conditions. The 
distributed system implementing the invention is disclosed in Figure 2. 

In the present embodiment, the event router 50 observes which objects enter the 
distributed environment. It does this either by using a discovery protocol or checking with look- 
5 up services. It contains within it a set of rules that describe which generators and which listeners 
to connect, as well as which events within a particular generator it should have hsteners 
subscribe to. Alternately, it may retrieve those rules dynamically from one or more specialized 
services. In the preferred embodiment these rules may be dynamically modified. 

In Figure 2 object, LI 40, L2 42 and L3 44 are listeners. The even router 50 stores the 
10 proxies 40a, 42a, 44a for each of these listeners. Objects SI 30, S2 32 and S3 34 emit events. 
The event router loiows from its mternal rules which types of events to route to which types of 
Usteners. In the example, each source emits a number of events, although sources may emit only 
one type of event. The event router 50 distributes the appropriate proxies to each source so that 
each event is routed to the appropriate hstener according to a set of rules. In Figure 2, each event 
15 is transmitted to the hstener whose proxy (or proxies) is attached to it. The proxies in the figure 
can be distinguished by the internal hash lines (horizontal, vertical, diagonal). Each proxy has 
the same hash marks as its hstener. The table below shows the routing for Figure 2. 



Event Listener 

la LI 

20 lb L3 

Ic L3 

2a LI 

2b none 

2c LI 

25 3a L2, L3 

3b LI 
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The arrows in Figure 2 indicate the event communication path for SI events (S2 and S3 
paths are not shown). Note that some events may have multiple listeners (Event 3a) or no 
listeners (Event 2b) and listeners may listen to multiple events from multiple sources. 

For example, one listener may be a security monitor and may want to be notified of any 
5 time that a user enters into the distributed envu'onment. The event router would Icnow that 
certain types of object, which are generators, are capable of logging in and admitting users. In 
this example, assume there are different objects that handle local login, remote login through 
dial-up access, and login through internet access; when any of these objects are present, they are 
identified as generators and the event router uses a rule to connect their events to the security 
10 module, which is the listener. Another object may want to listen for all events in the system and 
write these to a log. This object would be connected by the router to every other object in the 
system that emits events. 

The advantage can be readily seen which is instead of each listener having to discover 
each and every object in the system and subscribe to event notification, the event router 50 

15 handles this task across the system. The event router 50 can have very simple policies or 

complex policies, or it could retrieve (updated) policies from other services. Also, instead of 
these policies being written into each listener, they are written into the event router 50. In this 
.particular embodiment, the event router 50 downloads the proxy 40a, 42a, 44a for each listener 
40, 42, 44 and distributes it to the appropriate generators 30, 32, 34 so that generators can 

20 transmit events directly to the listener. The event router 50 is not involved in the transmission 
path of event notification, nor does it, in the preferred embodiment, determine the rules for 
establishing connections. In an alternate embodiment it may determine the rules using its own 
software. 
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Generators and listeners need not be software, but may be hardware, firmware, or a 
combination of software, hardware and firmware. As an example communication network 
hardware (such as signal routers) often emit events to announce occurrences such as errors, 
capacity levels, switching, status or merely pulses that they are alive. Various software modules 

5 may be interested in receiving these events. A system log service may want to receive all events 
fi:om a piece of network hardware. A security service may only want to receive security alerts 
fi-om those pieces of hardware that issue security events. A system status service may wish to 
receive status events fi-om all hardware routers. Each of these rules would be entered into the 
event router. These rules can be very specific (connect hardware piece 732 to the ABC security 

10 monitors) or more general (connect all firewalls to any security monitor). As each listener enters 
the system, the event router downloads its proxy. When a generator that the listener should 
register with (based on the rules) enters the system, the event router distributes the listener's 
proxy to the generator. 

In the preferred embodiment the polices in the event router can be changed dynamically 
15 by an operator or another object in the distributed environment. 

An object can be both a source or a listener wdth respect to other objects in the distributed 
application. 

The event router may also redirect certain notices to logs or to Tuple spaces (also known 
as JavaSpaces within Jini Applications) as shown in Figure 3. Now instead of all events going to 
20 particular listeners, the events are deposited within the JavaSpace where the listeners can 

monitor to see if any relevant events occurred. One advantage of this particular implementation 
is that load on the generator is minimized: the event generator produces and transmits only one 
event, rather than transmitting one for each listener (this is done when the listeners talce relevant 
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events from the JavaSpace). Another advantage derives from the event router's wrapper; since 
events in a JavaSpace are leased, the wrapper can renew the event's lease with the JavaSpace for 
a designated period of time, or even until it is taken from the JavaSpace. 

Numerous advantages pertain to systems with an event router. First event listeners do 
5 not need to register with generators. The event router perfonns this task, as well as any other 
tasks associated with establishing and maintaining the generator-hstener relationship. This adds 
flexibility to an executing system in that generator-hstener relationships need not be predicted or 
known in advance (only event types) and allows listeners to perform only the task of listening 
and event processing, rather than connection establishment and maintenance. Another advantage 
10 is that the event router can enforce system-wide security policies by connecting only authorized 
or authenticated listeners with generators. Another advantage is that the event router's 
wrappers enhance listeners' proxies. Finally, the ability of the event router to access routing 
rules from other services means that the set of generator-hstener relationships can be modified as 
required by the conditions in the system at any given time. 

15 Examples of generator-listener relationship rules for an event router are: 

Network Elements 

-Find all network element Jini services and register a listener that places all 
generated events in a JavaSpace 

-Find all network element Jini services that emit a PacketLossAlarm event and 
20 register both the "AlarmSpace" and the NetworkAdministrator listeners. 

Billing System Security 

- Connect all services that emit UserAutlientication events with all 
SystemAdministrator, SecurityLog, and UsageDisplay listeners. 
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Failure Detection 

- Connect all services that emit LeaseExpired and RemoteMethodException 
events with all FailureDetector listeners. 

While the disclosed embodiments have shown a single event router, multiple event 
routers may be used either for redundancy, to handle different sets of objects, or to implement 
different policies. 

The invention may also be practiced in combination with groups of objects, with a group 
acting as either an event soiirce or Ustener. 

It is understood that the invention is not limited to the disclosed embodiments, but on the 
contrary, is intended to cover various modifications and equivalent arrangements included within 
the spirit and scope of the appended claims, Witliout further elaboration, the foregoing will so 
fully illustrate the invention, that others may by current or future Icnowledge, readily adapt the 
same for use under the various conditions of service. 

1 
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1 



We claim: 



1 



1 . A distributed computing system comprising 



2 



a plurality of event generators; 



3 



a plurality of event listeners; 



4 



an event router; 



5 



a set of connection rules; 



6 wherein the event router detects the event generators and event listeners and connects the event 

7 generators and events hsteners according to the coimection rules. 

1 2. The distributed computing system of claim 1 wherein a connection is made by registering an 

2 event listener with an event generator. 

1 3. The distributed computing system of claim 1 wherein a coimection is made by directing 

2 events to a Tuple Space. 

1 4. The distributed computing system of claim 1 wherein the event generator is a status monitor, 

2 network hardware, or system login module. 

1 5. The distributed computing system of claim 1 wherein the event listener is a log service, 

2 security monitor, e-mail or beeper. 

1 6. A method of monitoring events m a distributed computing system comprising: 

2 an event router discovering objects in the system; 

3 the event router applying a set of rules to the objects to determine which of the objects 

4 are event generators and which objects are event hsteners; and 

5 the event router connecting an event generator to an event hstener. 
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1 7. The method of claim 6 wherein the step of coimecting the event generator to the event 

2 listener is comprised of registering the.event listener with the event generator. 

1 8. The method of claim 6 wherein the step of coimecting the event generator is accomplished via 

2 a Tuple Space. 



4 
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